Application model的用處是在於能整合所有到目前為止的所有user story，讓所有人都能簡單明瞭的知道我們程式的行為(Behavior)是什麼。也就能滿足CALMS裡的Sharing以及three ways的amplify feedback loop。

為什麼我們需要一個程式模型(application model)？

1. 能夠傳達確切的規格，記錄下來的文字可能因為讀者不同而有不同的解釋，圖片和箭頭只有一種解讀方法。
2. 圖片能讓技術人員和非技術人員都容易理解
3. 自動測量覆蓋率 (test coverage)
4. 自動生成測試用例 (test scenario & test case)

我們來看看一個application model如何幫助開發和測試。

修改前的主頁只有兩個input field，username和password。

Username和password有可能出現的情況如下：

所以username有四種可能性，password有三種可能性，如果每一種組合都要測試的話就需要4x3=12個不同的test case。不過不是每一種組合都需要被測試到，例如說如果沒輸入帳號的話那也不需要檢查密碼。

要在大腦裡試著整理和記住這些所有不同的情況是非常耗腦力的。也有可能造成某些功能過度重複測試或重要功能上測試不足，許多客戶都有這個困擾。

我有過一個客戶因為沒有考慮到一些特殊acces rights的組合沒被測試到所以造成了安全漏洞，因此讓公司被政府罰了一百多萬美金。

不過這個主頁相當簡單，所以QA只花了一點時間就把下列的組合想好了，並且記到Excel裡：

好，問題來了，我們新的checkbox加入後有多少組合會被影響到？如果再加入一個新的username status(例如帳號需要被activate)呢？QA在想完這些組合後還有多少精力去照一個80幾步的Excel runbook測試程式？

所以我們要做的是把軟體的邏輯紀錄在模型裡，讓模型軟體算出所有測試需要的組合。

製作模型的步驟很簡單：

1. 從結果開始想，列出所有可能的結果。以主頁的例子就是登入和無法登入。

2. 製造足夠通過的邏輯步驟。

3. 補上negative logic.

在加入昨天的user story邏輯後，新的網頁和模型如下：

我們可以看到，我們只需要在模型裡加入兩個部分，第一是一開始檢查用戶是不是之前已經選擇remember me，第二是最後檢查主頁上的remember me是否被選擇。運用模型時我們不需要去考慮所有username，password和checkbox的所有組合。

明天我們一起來看如何運用上面的application model來製造所有測試新加入的checkbox所需要的test case。

< 上一篇 Day05 - User Story & Requirements Modeling (Part 1)
> 下一篇 Day07 - Test case management